home *** CD-ROM | disk | FTP | other *** search
/ Graphics Plus / Graphics Plus.iso / formats / anim / anim310.arc / ANIM.doc next >
Encoding:
Text File  |  1987-06-12  |  9.9 KB  |  218 lines
  1.                               A N I M
  2.                   An IFF Format For CEL Animations
  3.  
  4.                      prepared by:
  5.                           Sparta Inc.
  6.                           23041 de la Carlota
  7.                           Laguna Hills, Calif 92653
  8.                           714) 768-8161
  9.                           contact: Gary Bonham
  10.  
  11.                      also by:
  12.                           Aegis Development Co.
  13.                           2115 Pico Blvd.
  14.                           Santa Monica, Calif 90405
  15.                           213) 392-9972
  16.  
  17. 1.0 Introduction
  18.     
  19.     The ANIM IFF format was developed at Sparta originally for the
  20.     production of animated video sequences on the Amiga computer.  The
  21.     intent was to be able to store, and play back, sequences of frames
  22.     and to minimize both the storage space on disk (through compression)
  23.     and playback time (through efficient de-compression algorithms).
  24.     It was desired to maintain maximum compatibility with existing
  25.     IFF formats and to be able to display the initial frame as a normal
  26.     still IFF picture.
  27.     
  28.     The basic ANIM format described here has been in use for over a year
  29.     in-house at Sparta with the XOR mode.  The delta mode is a recent,
  30.     and very effective, addition/improvement.
  31.     
  32.     1.1 IFF File Format Overview
  33.         
  34.         The general philosophy of ANIMs is to present the initial frame
  35.         as a normal, run-length-encoded, IFF picture.  Subsequent
  36.         frames are then described by listing only their differences
  37.         from a previous frame.  Normally, the "previous" frame is two
  38.         frames back as that is the frame remaining in the hidden 
  39.         screen buffer when double-buffering is used.  To better
  40.         understand this, suppose one has two screens, called A and B,
  41.         and the ability to instantly switch the display from one to
  42.         the other.  The normal playback mode is to load the initial
  43.         frame into A and duplicate it into B.  Then frame A is displayed
  44.         on the screen.  Then the differences for frame 2 are used to
  45.         alter screen B and it is displayed.  Then the differences for
  46.         frame 3 are used to alter screen A and it is displayed, and so
  47.         on.  Note that frame 2 is stored as differences from frame 1,
  48.         but all other frames are stored as differences from two frames
  49.         back.
  50.         
  51.         ANIM is an IFF FORM and its basic format is as follows (this
  52.         assumes the reader has a basic understanding of IFF format
  53.         files):
  54.                         FORM ANIM
  55.                         . FORM ILBM         first frame
  56.                         . . BMHD                normal type IFF data
  57.                         . . CMAP
  58.                         . . BODY
  59.                         . FORM ILBM         frame 2
  60.                         . . ANHD                animation header chunk
  61.                         . . DLTA                delta mode data
  62.                         . FORM ILBM         frame 3
  63.                         . . ANHD
  64.                         . . DLTA
  65.                              ...
  66.         
  67.         The initial FORM ILBM can contain all the normal ILBM chunks,
  68.         such as CRNG, etc.  The BODY will normally be a standard
  69.         run-length-encoded data chunk (but may be any other legal
  70.         compression mode as indicated by the BMHD).
  71.         
  72.         The subsequent FORMs ILBM contain an ANHD, instead of a BMHD,
  73.         which duplicates some of BMHD and has additional parameters
  74.         pertaining to the animation frame.  The DLTA chunk contains
  75.         the data for the two available delta compression modes.  If
  76.         the older XOR compression mode is used, then a BODY chunk
  77.         will be here.  In addition, other chunks may be placed in each
  78.         of these as deemed necessary (and as code is placed in player
  79.         programs to utilize them).  A good example would be CMAP chunks
  80.         to alter the color palette.  A basic assumption in ANIMs is
  81.         that the size of the bitmap, and the display mode (e.g. HAM)
  82.         will not change through the animation.
  83.         
  84.     1.2 Recording ANIMs
  85.         
  86.         To record an ANIM will require three bitmaps - one for 
  87.         creation of the next frame, and two more for a "history" of the
  88.         previous two frames for performing the compression calculations
  89.         (e.g. the delta mode calculations).
  90.         
  91.         There are three frame-to-frame compression methods currently
  92.         defined:
  93.         
  94.         1.2.1 XOR mode
  95.             
  96.             This mode is the original and is included here for
  97.             compatibility with some programs which still can output
  98.             this mode.  In general, the delta modes are far superior.
  99.             The creation of XOR mode is quite simple.  One simply
  100.             performs an exclusive-or (XOR) between all corresponding
  101.             bytes of the new frame and two frames back.  This results
  102.             in a new bitmap with 0 bits wherever the two frames were
  103.             identical, and 1 bits where they are different.  Then this
  104.             new bitmap is saved using run-length-encoding.  A major
  105.             obstacle of this mode is in the time consumed in performing
  106.             the XOR upon reconstructing the image.
  107.             
  108.         1.2.2 Long Delta mode
  109.             
  110.             This mode stores the actual new frame long-words which are
  111.             different, along with the offset in the bitmap.  The
  112.             exact format is shown and discussed in section 2 below.
  113.             Each plane is handled separately, with no data being saved
  114.             if no changes take place in a given plane.  Strings of
  115.             2 or more long-words in a row which change can be run
  116.             together so offsets do not have to be saved for each one.
  117.             
  118.             Constructing this data chunk usually consists of having
  119.             a buffer to hold the data, and calculating the data as
  120.             one compares the new frame, long-word by long-word, with
  121.             two frames back.
  122.             
  123.         1.2.3 Short Delta mode
  124.             
  125.             This mode is identical to the Long Delta mode except that
  126.             short-words are saved instead of long-words.  In most
  127.             instances, this mode results in a smaller DLTA chunk.
  128.             The Long Delta mode is mainly of interest in improving
  129.             the playback speed when used on a 32-bit 68020 Turbo Amiga.
  130.             
  131.     1.3 Playing ANIMs
  132.         
  133.         Playback of ANIMs will usually require two buffers, as mentioned
  134.         above, and double-buffering between them.  The frame data from
  135.         the ANIM file is used to modify the hidden frame to the next
  136.         frame to be shown.  When using the XOR mode, the usual run-
  137.         length-decoding routine can be easily modified to do the 
  138.         exclusive-or operation required.  Note that runs of zero bytes,
  139.         which will be very common, can be ignored, as an exclusive or
  140.         of any byte value to a byte of zero will not alter the original
  141.         byte value.
  142.         
  143. 2.0 Chunk Formats
  144.     2.1 ANHD Chunk
  145.         The ANHD chunk consists of the following data structure:
  146.         
  147.              UBYTE operation (=0 set directly,
  148.                               =1 XOR mode,
  149.                               =2 Long Delta mode,
  150.                               =3 Short Delta mode)
  151.              UBYTE mask      (XOR mode only - plane mask where each
  152.                               bit is set =1 if there is data and =0
  153.                               if not.)
  154.              UWORD w,h       (XOR mode only - width and height of the
  155.                               area represented by the BODY to eliminate
  156.                               unnecessary un-changed data)
  157.              WORD  x,y       (XOR mode only - position of rectangular
  158.                               area representd by the BODY)
  159.              ULONG abstime   (currently unused - timing for a frame
  160.                               relative to the time the first frame
  161.                               was displayed - in jiffies (1/60 sec))
  162.              ULONG reltime   (timing for frame relative to time
  163.                               previous frame was displayed - in
  164.                               jiffies (1/60 sec))
  165.              UBYTE interleave (unused so far - indicates how may frames
  166.                                back this data is to modify.  =0 defaults
  167.                                to indicate two frames back (for double
  168.                                buffering). =n indicates n frames back.
  169.                                The main intent here is to allow values
  170.                                of =1 for special applications where
  171.                                frame data would modify the immediately
  172.                                previous frame)
  173.              UBYTE pad[21]    (this is a pad for future use for future
  174.                                compression modes.  Some of these - maybe
  175.                                16 - are intentionally provided for use
  176.                                by Jim Kent for operation codes for each
  177.                                plane and other ancillary data he
  178.                                requested)
  179.         
  180.         
  181.     2.2 DLTA Chunk
  182.         
  183.         This chunk is a basic data chunk used to hold the delta
  184.         compression data.  The minimum size of this chunk is 32 bytes
  185.         as the first 8 long-words are byte pointers into the chunk for
  186.         the data for each of up to 8 bitplanes.  The pointer for the
  187.         plane data starting immediately following these 8 pointers will
  188.         have a value of 32 as the data starts in the 33-rd byte of the
  189.         chunk (indes value of 32 due to zero-base indexing).
  190.         
  191.         The data for a given plane consists of groups of data words.  In
  192.         Long Delta mode, these groups consist of both short and long
  193.         words - short words for offsets and numbers, and long words for
  194.         the actual data.  In Short Delta mode, the groups are identical
  195.         except data words are also shorts so all data is short words.
  196.         Each group consists of a starting word which is an offset.  If
  197.         the offset is positive then it indicates the increment in long
  198.         or short words (whichever is appropriate) through the bitplane.
  199.         In other words, if you were reconstructing the plane, you would
  200.         start a pointer (to shorts or longs depending on the mode) to
  201.         point to the first word of the bitplane.  Then the offset would
  202.         be added to it and the following data word would be placed at
  203.         that position.  Then the next offset would be added to the
  204.         pointer and the following data word would be placed at that
  205.         position.  And so on...  The data terminates with an offset
  206.         equal to 0xFFFF.
  207.         
  208.         A second interpretation is given if the offset is negative.  In
  209.         that case, the absolute value is the offset+2.  Then the 
  210.         following short-word indicates the number of data words that
  211.         follow.  Following that is the indicated number of contiguous
  212.         data words (longs or shorts depending on mode) which are to
  213.         be placed in contiguous locations of the bitplane.
  214.         
  215.         If there are no changed words in a given plane, then the pointer
  216.         in the first 32 bytes of the chunk is =0.
  217.         
  218.